Celestin Apprentice 2/Apprentice-Release2.iso/Information/Digests/CSMP Digest/volume 3/csmp-digest-v3-066

Text File | 1994-12-08 | 162.2 KB | 2,602 lines | [TEXT/R*ch]

C.S.M.P. Digest             Mon, 07 Nov 94       Volume 3 : Issue 66

Today's Topics:

        #defines by the compiler (CodeWarrior)
        Announcement: New Mac C++ Programming Book Available
        Apple Guide:  Styled text FUBAR
        Basic GWorlds and QuickDraw Newbie
        CW & Code Resources -- poor?
        Desktop Pictures
        Drag-and-drop to cdev window?
        Fastest way to fill memory with a given value?
        Gestalt Selectors List 2.6
        Global storage in code resources
        How to execute MPW tools without MPW
        MacTCP Completion Routines & Async Nofification
        Memory Management within the Real World
        NewGWorld returns null pointer
        Pathnames? I don't think so...
        Q: Creating Variable sized structures?
        QuickTime + MIDI?
        Software volume locking: HELP!
        Some string routines for the PowerPC
        Tech Notes on the World Wide Web, and History Is Made



The Comp.Sys.Mac.Programmer Digest is moderated by Francois Pottier
([e-mail]).

The digest is a collection of article threads from the internet newsgroup
comp.sys.mac.programmer.  It is designed for people who read c.s.m.p. semi-
regularly and want an archive of the discussions.  If you don't know what a
newsgroup is, you probably don't have access to it.  Ask your systems
administrator(s) for details.  If you don't have access to news, you may
still be able to post messages to the group by using a mail server like
anon.penet.fi (mail [e-mail] for more information).

Each issue of the digest contains one or more sets of articles (called
threads), with each set corresponding to a 'discussion' of a particular
subject.  The articles are not edited; all articles included in this digest
are in their original posted form (as received by our news server at
nef.ens.fr).  Article threads are not added to the digest until the last
article added to the thread is at least two weeks old (this is to ensure that
the thread is dead before adding it to the digest).  Article threads that
consist of only one message are generally not included in the digest.

The digest is officially distributed by two means, by email and ftp.

If you want to receive the digest by mail, send email to [e-mail]
with no subject and one of the following commands as body:
    help                        Sends you a summary of commands
    subscribe csmp-digest Your Name    Adds you to the mailing list
    signoff csmp-digest            Removes you from the list
Once you have subscribed, you will automatically receive each new
issue as it is created.

The official ftp info is //ftp.dartmouth.edu/pub/csmp-digest.
Questions related to the ftp site should be directed to
[e-mail]. Currently no previous volumes of the CSMP
digest are available there.

Also, the digests are available to WAIS users.  To search back issues
with WAIS, use comp.sys.mac.programmer.src. With Mosaic, use
http://www.wais.com/wais-dbs/comp.sys.mac.programmer.html.


-------------------------------------------------------

>From [e-mail] (joe zobkiw)
Subject: #defines by the compiler (CodeWarrior)
Date: Mon, 17 Oct 1994 13:45:40 GMT
Organization: Datawatch Corporation

I have been writing some Aladdin InstallerMaker extensions recently and
have a nice little system that (using two projects and a "switch" in my
main source file) allows me to compile the extension as an application for
easy testing. Then, when I'm done, I can switch projects, switch the
#define switch in my main source file, and compile it as the proper
resource type.

My question is, since CodeWarrior doesn't have a nice little "Prefix" type
per-project option like THINK C had, is there another way? It would be
great if the compiler knew what TYPE it was compiling the code as and I
could get at this information in my code. Something like:

#ifdef APPL               // APPL is the TYPE of the project
  InitializeMacintoshManagers();
#endif

#ifdef IBeg               // IBeg is the RESOURCE TYPE of the project
   SysBeep(0);
#endif

Is there another way to accomplish this? Any thoughts?

_______________________________________________________ ,,,
Joe Zobkiw                         [e-mail] - -
Senior Software Engineer          Datawatch Corporation  L
___________ Zeros and Ones will take us there __________ _

+++++++++++++++++++++++++++

>From [e-mail] (MW Ron)
Date: 17 Oct 1994 12:22:03 -0400
Organization: America Online, Inc. (1-800-827-6364)

In article <[e-mail]>,
[e-mail] (joe zobkiw) writes:

>>My question is, since CodeWarrior doesn't have a nice little "Prefix"
type per-project option like THINK C had, is there another way? It would
be great if the compiler knew what TYPE it was compiling the code as and I
could get at this information in my code.


The "Prefix File" option in the Languages Preferences lets you specify
a file that gets automatically prepended to every file. Be default, it is
set to the precompiled header for the Toolbox routines. However, you can
specify your own file.

For example, you could specify a Prefix File of  MyPrefix.h, where the
contents of MyPrefix.h was:

#include <MacHeaders68K>   // Included precompiled header
            // Define Symbols

#ifdef APPL               // APPL is the TYPE of the project
  InitializeMacintoshManagers();
#endif

#ifdef IBeg               // IBeg is the RESOURCE TYPE of the project
   SysBeep(0);
#endif

Your Prefix File can contain any valid C statements.

Ron Liechty
[e-mail]
Metrowerks Inc.



---------------------------

>From [e-mail] (DanParks)
Subject: Announcement: New Mac C++ Programming Book Available
Date: 15 Oct 1994 16:56:04 -0400
Organization: America Online, Inc. (1-800-827-6364)

//******************************************************
   Apologies if this isn't the proper newsgroup for this message.
   I posted it to comp.sys.mac.announce, but it was returned as
         "not acceptable topic for this newsgroup" !!
//******************************************************

To All:

There's a new Mac programming book now available - "Symantec C++:
Object-Oriented Programming Fundamentals for the Macintosh" by Prima
Publishing. It should be at your bookstore by the time you read this.

"Symantec C++:  Object-Oriented Programming Fundamentals for the
Macintosh"
Dan Parks Sydow
Prima Publishing
ISBN:  1-55958-633-8

The book assumes the reader has a knowledge of a higher-level language -
preferably the C language. It also assumes the reader has done at least a
little programming on the Mac. No advanced-level programming skills are
needed, and no previous knowledge of C++ is required.

Like my previous Prima book, "Think THINK C", this book comes bundled with
a disk that contains ALL of the source code examples presented in the
book. It also has a tutorial software program that covers the major topics
from the book, from a little different perspective. That program is called
Simulator C++. The purpose of the software is to "bring to life" the
concepts in the book through the use of text, graphics, QuickTime movies,
and on-screen questions and answers.

All examples in the book work with Symantec C++ version 6 or version 7.
All examples run on either a 680x0 Mac or a Power Mac. There are a couple
of dozen example programs - most of them short and covering just a single
key topic. But there are also a couple of larger programs that incorporate
many C++/object-oriented programming concepts. Earlier examples stress
basic techniques, later examples stress programming C++ using Macintosh
techniques - writing programs that make use of menus, dialogs, windows,
resources, and graphics.

As always, please feel free to send email to me ( addresses shown below)
with any comments/suggestions/kind words/complaints/questions.

*Note to CodeWarrior Owners*
If you want to learn C++ programming for the Mac, this book MAY be for
you. You'd have to be willing to skip one chapter of the book, and make
minimal changes to the source code. You CodeWarrior owners shouldn't have
too much trouble adapting the examples to your Metrowerks compiler. You'll
need to create a new project, then add the included source code file to
it. Most source code files need only one or two changes to compile with
CodeWarrior. I'll be posting an errata sheet in this newsgroup next week
for CodeWarrior users. It will detail the changes that need to be made.

Internet:  [e-mail]
CompuServe:   73747,1401
America Online:  DanParks


Regards,

Dan



+++++++++++++++++++++++++++

>From [e-mail] (joe zobkiw)
Date: Mon, 17 Oct 1994 13:38:50 GMT
Organization: Datawatch Corporation

In article <37pfl4$[e-mail]>, [e-mail] (DanParks)
wrote:

> //******************************************************
>    Apologies if this isn't the proper newsgroup for this message.
>    I posted it to comp.sys.mac.announce, but it was returned as
>          "not acceptable topic for this newsgroup" !!
> //******************************************************
>

How could the Macintosh programmers newsgroup not be the right place for
an announcement about a new book about Macintosh programming? :)

This damn info-super-highway has everyone afraid of getting flamed for the
littlest thing, much like most kids in the inner-city are afraid to go to
school because they'll get shot. So what do they do? Skip school and not
post.

Dan, it sounds like a good book. Thanks for the info.

_______________________________________________________ ,,,
Joe Zobkiw                         [e-mail] - -
Senior Software Engineer          Datawatch Corporation  L
___________ Zeros and Ones will take us there __________ _

---------------------------

>From [e-mail] (Charles Wiltgen)
Subject: Apple Guide:  Styled text FUBAR
Date: Sat, 22 Oct 1994 18:09:26 -0500
Organization: Muso Communications

It's a major pain to use styled text in Apple Guide.  Basically, I can't
make any hypertext links stand out because Apple didn't think of including
an "embolden" tag in the dang compiler.

What is everyone using to create Apple Guide files with?  SimpleText is
out of the question.  I'd like to use WriteNow, but the GuideMaker crashes
when it tries to read it.

Anyone have a solution?

--
Charles Wiltgen    "Love is a snowmobile racing across the tundra and
[e-mail]    then suddenly it flips over, pinning you underneath.
(INTP)              At night, the ice weasels come." - Nietzsche (Groening)
The Apocalypso!     http://www.mcs.net/~cwiltgen

+++++++++++++++++++++++++++

>From [e-mail] (Quinn "The Eskimo!")
Date: Sun, 23 Oct 1994 11:01:58 +0800
Organization: Department of Computer Science, The University of Western
Australia

In article <[e-mail]>,
[e-mail] (Charles Wiltgen) wrote:

>It's a major pain to use styled text in Apple Guide.  Basically, I can't
>make any hypertext links stand out because Apple didn't think of including
>an "embolden" tag in the dang compiler.

Yep, I've found this very annoying too.  I basically gave up on hot text,
at least for the moment.

>What is everyone using to create Apple Guide files with?

I use TexEdit.  It's a pretty cool shareware styled text editor.  [And
yes, I have sent off my shareware payment.]  Unfortunately there's no XTND
filter for it, so the styles don't move across to AG.

>I'd like to use WriteNow, but the GuideMaker crashes
>when it tries to read it.

I had *exactly* the same problem.  I think (god forbid) that MS Word might
be a good choice.  As long as you restrict yourself to the core features
it's fairly nice and the XTND filters are likely to be more stable.
However my hard disk is Microsloth-free, which eliminates this option for
me.

Share and Enjoy.
--
Quinn "The Eskimo!"      "I wasn't the one who fired the heat seeking
                          population annihilator out the window!"

+++++++++++++++++++++++++++

>From [e-mail] (Charles Wiltgen)
Date: Sun, 23 Oct 1994 12:43:14 -0500
Organization: Muso Communications

In article <[e-mail]>,
[e-mail] (Quinn "The Eskimo!") wrote:

> >It's a major pain to use styled text in Apple Guide.  Basically, I can't
> >make any hypertext links stand out because Apple didn't think of including
> >an "embolden" tag in the dang compiler.
>
> Yep, I've found this very annoying too.  I basically gave up on hot text,
> at least for the moment.

That's potentially one of the Best ThingsTM about Apple Guide, and we can't
use it because there's no way to find out what what's hot-clickable.  I'm
going to use Word on one of my smaller files (but I'm afraid!) or go to
some sort of <<click here>> notation for now.

> >I'd like to use WriteNow, but the GuideMaker crashes
> >when it tries to read it.
>
> I had *exactly* the same problem.  I think (god forbid) that MS Word might
> be a good choice.  As long as you restrict yourself to the core features
> it's fairly nice and the XTND filters are likely to be more stable.
> However my hard disk is Microsloth-free, which eliminates this option for
> me.

Thanks for the confirmation.  I got WriteNow for $12.95 when I ordered
something from MacWarehouse (don't tell anyone about this special offer!)
and thought it would be perfect for this.  Alas, it was not to be.

C'mon, Apple!  Add those <B>style</B> tags!!!

--
Charles Wiltgen    "Love is a snowmobile racing across the tundra and
[e-mail]    then suddenly it flips over, pinning you underneath.
(INTP)              At night, the ice weasels come." - Nietzsche (Groening)
The Apocalypso!     http://www.mcs.net/~cwiltgen

+++++++++++++++++++++++++++

>From [e-mail] (Charles Wiltgen)
Date: Sun, 23 Oct 1994 13:41:56 -0500
Organization: Muso Communications

In article <[e-mail]>,
[e-mail] (Charles Wiltgen) wrote:

> > I think (god forbid) that MS Word might
> > be a good choice.  As long as you restrict yourself to the core features
> > it's fairly nice and the XTND filters are likely to be more stable.
> > However my hard disk is Microsloth-free, which eliminates this option for
> > me.

Nope, Word doesn't work either (although Guide reads Word files fine).

Can someone from Apple help?  I've already started doing my hot words like
'this$BB...

--
Charles Wiltgen    "Love is a snowmobile racing across the tundra and
[e-mail]    then suddenly it flips over, pinning you underneath.
(INTP)              At night, the ice weasels come." - Nietzsche (Groening)
The Apocalypso!     http://www.mcs.net/~cwiltgen

---------------------------

>From [e-mail] (Jared P. O'neal)
Subject: Basic GWorlds and QuickDraw Newbie
Date: 18 Oct 1994 21:28:47 GMT
Organization: Case Western Reserve University, Cleveland, Ohio (USA)


I've created a GWorld, at least I think I have.  Then, I used the
GetGWorldPixMap() call to get the handle of the PixMap.  All I wanted to do
was
use CopyBits to take a picture I had put into the GWorld w/ DrawPicture onto
a
window I had created, but when I tried it, it didn't copy anything into the
window.  When I tried to debug it (just how do you debug a GWorld), I noticed
that the baseaddr was 0, which doesn't seem right.  Is there anything I did
wrong here?  (I left out the error handling stuff)

GetGWorld(&origPort, &origDev);
    myErr = NewGWorld(&myGWorldPtr, 0, &myRect, nil, nil, 0);
    SetGWorld(myGWorldPtr, nil);
    myPixMapHnd = GetGWorldPixMap(myGWorldPtr);
    good = LockPixels(myPixMapHnd);
    wndoRect = myGWorldPtr->portRect;
    EraseRect(&wndoRect);

if (PictID != 0)
    {
        myPic = GetPicture(PictID);
        DrawPicture(myPic, &myRect);
    }

    SetGWorld(origPort, origDev);

    SetPort(wp);

CopyBits((BitMap *)*myPixMapHnd, (BitMap *)wp, &wndoRect, &(wp->portRect), 0,
nil);

where wp is the WindowPtr of the destination window.

--Jared
--
Philosophy:  Master the colonel's secret blend of herbs & spices and all the
secrets of the universe will be yours!?!

Jared O'Neal aka [e-mail] or [e-mail] or
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Alex Curylo)
Date: 19 Oct 1994 07:43:58 GMT
Organization: First Ascent

In article <381emf$[e-mail]>
[e-mail] (Jared P. O'neal) writes:

> Is there anything I did wrong here?
>CopyBits((BitMap *)*myPixMapHnd, (BitMap *)wp, &wndoRect, &(wp->portRect),
0, nil);

Yes. (BitMap *)*myPixMapHnd is wrong. Changing that to
&((GrafPtr)myGWorldPtr)->portBits should make it work just fine. And
(BitMap*)wp is wrong too. You want &((GrafPtr)wp)->portBits.

+++++++++++++++++++++++++++

>From [e-mail] (GBolsinga)
Date: 19 Oct 1994 15:24:02 -0400
Organization: America Online, Inc. (1-800-827-6364)

In article <382inu$[e-mail]>, [e-mail]
(Alex Curylo) writes:

>Yes. (BitMap *)*myPixMapHnd is wrong. Changing that to
>&((GrafPtr)myGWorldPtr)->portBits should make it work just fine. And

This is wrong! To quote NIM: Imaging With QuickDraw:
"To ensure compatibility on systems running basic QuickDraw instead of
Color Quickdraw, use GetGWorldPixMap whenever you need to gain
access to the bitmap created for a graphics world--that is, do NOT
dereference the GWorldPtr record for that graphics world."

The funny thing is, all the code samples for CopyBIts in the book that I
saw do the WRONG thing.  So many manuals, so little time... :)

The problem is with the second (destination) Bitmap: change it to:

&((GrafPtr)wp)->portBits

and thing should be fine.

Greg Bolsinga
MPI Multimedia

+++++++++++++++++++++++++++

>From [e-mail] (Alex Curylo)
Date: 24 Oct 1994 09:15:00 GMT
Organization: First Ascent

In article <[e-mail]>
[e-mail] (Robert Coie) writes:

> A word of caution about GetGWorldPixMap -- it was severely broken in
> pre-7.0 systems.  I think it grabbed a half word instead of a full 32-bit
> word.  If you are certain to be running on a post-7.0 system,
> GetGWorldPixMap should be OK.  If you are certain that Color QuickDraw is
> present and are concerned about System 6 compatibility, do the direct
> dereference.

Yes indeed. Version 1.2, to be exact. Like this:

    // GetGWorldPixMap doesn't work in 32CQD 1.2
    gLameCQD = (qdVersion >= gestalt32BitQD) && (qdVersion <
gestalt32BitQD13);

// workaround for GetGWorldPixMap bug in CQD 1.2
PixMapHandle OurGetGWorldPixMap(GWorldPtr world)
{
 if (gLameCQD)
     return ((CGrafPtr)world)->portPixMap;
 else
     return GetGWorldPixMap(world);
}

But in the particular case of CopyBits,
&((GrafPtr)myGWorldPtr)->portBits really does always work. Up to 7.5,
anyway.

---------------------------

>From [e-mail] (Andrew Francke)
Subject: CW & Code Resources -- poor?
Date: Wed, 12 Oct 1994 03:00:02 GMT
Organization: Netcom Online Communications Services (408-241-9760 login:
guest)

After perusing CodeWarrior C for a little Component Manager
development, I've formed the following reactions. Please respond with
the approriate answers.

Is it just me, or:

* is there no way to create a single-segment code resource that uses
  the MW ANSI libs?

* does the faux-segment loader just plain not work when the code
  resource's resource fork isn't open? when there are multiple
  multi-segment resources in the same file?

* is there no way to have the following declaration in an MW
  code resource:

    char *foo = "bar"

If the answer to the first question is "yes," when will MW ship an
intelligent linker? Yes, yes -- it's way better than the
THINK/Symantec linker in its identification of dead code. That doesn't
matter if it's convinced you need multiple segments based on the
*un*stripped code/data size.

If the answer to any part of the second question is "yes," when will
MW either: document the secret inner-workings of the multi-segment
glue? Heck, if the answer is *no,* when will MW document it?

The third question is based on the fuzzy observation (i.e., I didn't
ATFCO -- adjust the compiler options) that a struct with a char *
member could not be initialized with a static string.

Finally -- on an entirely unrelated note -- when will somebody prepare
a runtime library for MPW C-generated .o files that need such fine
symbols as _iob and LDIVU -- that can then be used in MW projects.

+++++++++++++++++++++++++++

>From [e-mail] (IsoChrome)
Date: 13 Oct 1994 14:10:01 -0400
Organization: America Online, Inc. (1-800-827-6364)

In article <[e-mail]>, [e-mail] (Andrew
Francke) writes:

> * does the faux-segment loader just plain not work when the code
>  resource's resource fork isn't open? when there are multiple
>  multi-segment resources in the same file?

I've had the same problem with CW (we're writing 'cmm ' components). The
component manager seems to cache the component code, so your resource fork
isn't open when you are called. It looks like CW keeps some sort of jump
table information in a separate resource ('cmmx' for 'cmm 's). The kiss of
death is that the resource is loaded before a single line of your code is
executed (to get the address of main maybe?), so there is no way you can
open the resource fork yourself. I've had to punt and compile the 68K
piece in Symantec and the PPC piece in CodeWarrior.

John Sarapata

+++++++++++++++++++++++++++

>From [e-mail] (Mark Hanrek)
Date: Sun, 16 Oct 1994 07:53:44 GMT
Organization: The Information Worskhop

In article <[e-mail]>, [e-mail] (Andrew
Francke) wrote:

Try posting your question in "comp.sys.mac.programmer.codewarrior" which
you may not have known existed.  It's new, and you may find an answer to
your question already posted, as I remember reading something along these
lines recently.

Mark Hanrek

+++++++++++++++++++++++++++

>From [e-mail] (Richard Buckle)
Date: Tue, 18 Oct 1994 07:51:57 GMT
Organization: none

In article <[e-mail]>,
[e-mail] (Andrew Francke) wrote:

>* is there no way to create a single-segment code resource that uses
>  the MW ANSI libs?

Not if you want to use any vaguely useful ANSI function, such as pow() or
tolower(). The problem is the dead-code stripping can't see through
libraries.
I've repeatedly suggested that MW sort this out and in the interim either
distribute cut-down ANSI libraries (string.lib, math.lib etc) without
32-bit links hard-wired in or at the very least distribute a 68020 build. I
have got *nowhere*.

>* does the faux-segment loader just plain not work when the code
>  resource's resource fork isn't open? when there are multiple
>  multi-segment resources in the same file?

Basically yes. It can also crash horribly if your multi-segment resource is
unlocked between calls to it and moves, as the 32-bit jumps do not get
remade. UnloadA4Seg() does not help. I have asked MW to provide a way to
tell the multi-segment resource to remake its jumps, such as calling
UnloadA4Seg(NULL), but this too has fallen on deaf ears.
Dammit, I feel strongly I should be entitled to unlock my code resources
between calls to them.
As I have no control over the third party app calling my code resource, I
have been reduced to building a stub single-seg resource that calls the
multi-seg resource, runs it and disposes of it to suit MW's brain-damaged
segmentation scheme. Mail me if you want details.

The whole segmentation thing on CodeWarrior *sucks*, on apps as well as
code resources. See a thread by Steve Dorner a while ago for a description
of the pure evil that is the application segment loader under CW.

A dreadful shame, as this apart from this huge blind spot MW have a *very*
fine product. Maybe some more net.pressure will do the trick.


- -----------------------------------------------------
Richard Buckle
[e-mail]
Using this darned fine NewsHopper thingy.


+++++++++++++++++++++++++++

>From Jens Alfke <[e-mail]>
Date: Tue, 18 Oct 1994 17:26:12 GMT
Organization: Apple Computer

Andrew Francke, [e-mail] writes:
> * does the faux-segment loader just plain not work when the code
>   resource's resource fork isn't open? when there are multiple
>   multi-segment resources in the same file?

I believe it will work as long as you preload and detach the code segments.
The loader obviously can't magically know how to open the resource file to
get the code.

> * is there no way to have the following declaration in an MW
>   code resource:
>     char *foo = "bar"

Should work fine as long as A4 is set up properly at the time that the global
data is referenced.

I've directed follow-ups to c.s.m.p.codewarrior.

--Jens Alfke                           [e-mail]
                   "A man, a plan, a yam, a can of Spam ... Bananama!"

+++++++++++++++++++++++++++

>From [e-mail] (Erik J. Rogers)
Date: Thu, 20 Oct 1994 01:59:30 GMT
OrgathePict ) ;
            oldFillCRgn = ( pascal void ( * ) ( RgnHandle ,
PixPatHandle ) ) GetToolTrapAddress ( 0xaa12 ) ;
            SetToolTrapAddress ( ( ProcPtr ) DrawDesk , 0xaa12 )
;
        }

        theBeep = GetResource ( 'snd ' , 4000 ) ;
        if ( theBeep ) {
            DetachResource ( theBeep ) ;
            SetToolTrapAddress ( ( ProcPtr ) DoBeep , 0xA9C8 ) ;
// SysBeep
        }
    }
    RestoreA4();
}



--
  Jon W$E4tte ([e-mail]), Hagagatan 1, 113 48 Stockholm, Sweden

"Smart Friends ask no SCSI questions!"
    a Apple employee at the Bash


---------------------------

>From [e-mail] (Lawrence D'Oliveiro, Waikato University)
Subject: Drag-and-drop to cdev window?
Date: 10 Oct 94 16:47:53 +1300
Organization: University of Waikato, Hamilton, New Zealand

I'm writing this control panel which supports the Drag Manager. I've hit an
odd problem: dragging Finder clipping files to my window doesn't seem to
work.

I stepped through my drag-tracking handler with MacsBug, and watched it check
for a PICT item type, by calling GetFlavorDataSize. If there is no PICT type,
I get badDragFlavorErr = -1852, which makes sense. If there _is_ a PICT type,
I get cantGetFlavorErr = -1854 instead.

If I drag a PICT item from another application to my control panel window,
it works OK, so I figure a bug in my code is unlikely. :-)

Anybody else encountered this? Maybe the problem is that control panels
run in the Finder's context, and its peculiar uses of the Drag Manager don't
allow for this.

Any ideas welcomed.

Lawrence D'Oliveiro                       fone: [phone]
Info & Tech Services Division              fax: [phone]
University of Waikato            electric mail: [e-mail]
Hamilton, New Zealand    37^ 47' 26" S, 175^ 19' 7" E, GMT+13:00

+++++++++++++++++++++++++++

>From [e-mail] (Jump Long)
Date: 11 Oct 1994 01:03:03 -0400
Organization: America Online, Inc. (1-800-827-6364)

In article <[e-mail]>, [e-mail]
(Lawrence D'Oliveiro, Waikato University) writes:

>I'm writing this control panel which supports the Drag Manager. I've hit
>an odd problem: dragging Finder clipping files to my window doesn't seem
>to work.

We had the same report at work and the answer is, it won't work.  I can't
remember the reason why, but Nitin tracked it down.

- Jim Luther

---------------------------

>From [e-mail] (Randy Jones)
Subject: Fastest way to fill memory with a given value?
Date: 14 Oct 1994 17:58:54 GMT
Organization: NWNEXUS, Inc. - We Make Internet Easy

I want to fill a given block of memory with copies of a long.
I'm guessing there has to be a faster way than a loop which
sets each word in turn.  BlockMove, for example, runs faster
than a copy loop.  But there's no Mac toolbox equivalent of
memset that I've found.

Are compilers smart enough to turn my loop of word writes into
something faster, maybe involving the MMU?  If not, then what
am I missing?  Think and/or MetroWerks C, BTW.

--Randy Jones



+++++++++++++++++++++++++++

>From [e-mail] (Richard Elmore)
Date: Sat, 15 Oct 1994 01:54:09 -0800
Organization: Northwest Nexus Inc.

In article <37mgsu$[e-mail]>, [e-mail] (Randy
Jones) wrote:

> I want to fill a given block of memory with copies of a long.
> I'm guessing there has to be a faster way than a loop which
> sets each word in turn.  BlockMove, for example, runs faster
> than a copy loop.  But there's no Mac toolbox equivalent of
> memset that I've found.

The most common way to speed up mem copy/fill operations is to unroll your
loop.  That is, instead of copying one long word during each iteration of
your loop copy several.  This is in fact the approach taken by
_BlockMove.  Another thing that will make a difference is to make sure all
of your moves are longword aligned (ever notice how Hypercard snaps its
windows an invisible grid on the screen, thats why).

--
Richard Elmore
[e-mail]

+++++++++++++++++++++++++++

>From Arnold Kim <[e-mail]>
Date: 16 Oct 1994 20:26:04 GMT
Organization: Nemesis Productions

In ttribute bits will keep appearing as the system software develops...

The note about the gestaltKeyboardType selector not being installed on
the PowerMac 7100/66 was triggered by an Usenet posting by Marc Cooperman.
His observation was confirmed by me because Gestalt! reports of the
PM 7100/66 indeed do not list this selector, but I never noticed this when
I received these reports! Other (Power)Macs don't seem to have this
problem.

The GSL has been made available by Robert Lentz on a World Wide Web server.
It now has the latest version and a reference to it is included with the
'About This List/Availability' section.

Included information from the:
 - Bookmark CD #18,
 - Bookmark CD #19,
 - WWDC 1994 CD,
 - Developer CD Series August 1994 Tool Chest CD and
 - Developer CD Series September 1994 Reference Library CD.

Roland Mansson provided the information from the latest Gestalt &
SysEnvirons TechNote (rev. September 1994). The most important news
is that the machine ID's will be reused...

The following selectors are now installed with software included with
System 7.5 and are moved from the 'Apple Additional Software' to the 'Apple
System Software' section:
      ascr, ascv, aucd, cpkr,
      drag, hscd, icmp, iscd,
      kpcd, mtcp, qtim, qtrs,
      scra, sdev, sdvr, snhw,
      teat, thds, ufox, xlat
And these from the unknown 'Third Party Software' to the unknown 'Apple
Software' section:
      CDJR, HAM , MClk
***************************************************************************


Best regards,
Rene Ros
[e-mail]

--
  Rene G.A. Ros           [e-mail]          Amsterdam, The
Netherlands
-
------------------------------------------------------------------------------

  English is deliberately designed to frustrate foreigners, you know...
  (Jeremy Roussak (UK) while trying to explain 'an/a' to me)

---------------------------

>From [e-mail] (Dan McDonald)
Subject: Global storage in code resources
Date: 14 Oct 1994 17:13:29 GMT
Organization: Information Technology Division, Naval Research Laboratory


With the advent of PowerPC, I'm again confused on something I thought I
knew.

I assumed that:

    * Global variables between procedures in a separate code resource
      were okay, as long as A4 was set up properly

If that assumption was wrong, fine.  If it's right, then

    * How the HELL do you set up A4 in PowerPC code resources?

I may end up designing my external code modules such that the module asks
the main program for storage, and the main program delivers, and
subsequently sends pointers to it whenever the code in the module is called.

Any comments, hints, death threats, etc. are vastly appreciated.
--
Daniel L. McDonald | Mail:  [e-mail]
-------------------------+
Computer Scientist | WWW:   http://wintermute.itd.nrl.navy.mil/danmcd.html
|
Naval Research Lab | Phone: [phone]        #include <disclaimer.h>
|
Washington, DC     | "Rise from the ashes, A blaze of everyday glory" - Rush
+

+++++++++++++++++++++++++++

>From [e-mail] (Mike Cohen)
Date: Sat, 15 Oct 1994 19:09:29 GMT
Organization: ISIS International

In article <37me7q$[e-mail]>, [e-mail]
(Dan McDonald) wrote:

> With the advent of PowerPC, I'm again confused on something I thought I
> knew.
>
> I assumed that:
>
>         * Global variables between procedures in a separate code resource
>           were okay, as long as A4 was set up properly
>
> If that assumption was wrong, fine.  If it's right, then
>
>         * How the HELL do you set up A4 in PowerPC code resources?
>
68K code resources still need to have A4 set up, but you don't have to do
anything in native code resources. In PPC code, every code fragment
(including code resources) has its own global space accessible thru the
RTOC, which a register is always pointing to when that code fragment is
executing.

--
Mike Cohen - [e-mail]
NewtonMail, eWorld: MikeC / ALink: D6734 / AOL: MikeC20
Home Page: ftp://ftp.netcom.com/pub/isis/home.html

---------------------------

>From [e-mail] (Zack T. Smith)
Subject: How to execute MPW tools without MPW
Date: Wed, 12 Oct 1994 13:58:39 GMT
Organization: NETCOM On-line Communication Services (408 261-4700 guest)

Hi,

I'd like to find out how I can execute MPW commands without
having MPW. I know that there is a program available for
doing this (toolserver), but I don't want to use it.

I notice that the MPW tool that I have (gcc) contains only code
and version resources. I've tried to execute that as a
standalone app by changing creator to FNDR and type to APPL,
but the program immediately exits.

Does anyone know why this might be happening, assuming that gcc
is not buggy. I've tried to inquire with Apple via email, but
they won't respond. My guess is that, if gcc had been
executing properly, it simply didn't find any params to work on,
so it exited.

Would anyone know whether it's necessary to load MPW tools
into memory in order to execute them and pass parameters?

Thanks for any info,

Zack Smith


+++++++++++++++++++++++++++

>From [e-mail] (Stan Shebs)
Date: Wed, 12 Oct 1994 18:52:22 GMT
Organization: /cygint/s1/users/shebs/.organization


In article <[e-mail]> [e-mail] (Zack T. Smith)
writes:

   I notice that the MPW tool that I have (gcc) contains only code
   and version resources. I've tried to execute that as a
   standalone app by changing creator to FNDR and type to APPL,
   but the program immediately exits.

Uh, MPW GCC requires considerable MPW infrastructure - for one thing,
it is a collection of tools, for another, it expects to be able to use
the MPW Assembler.  And where do you plan to get include files and
libraries?  Changing the file type to get it to run is about like
working the shift lever on an engineless car - it *might* start
rolling if you happen to shift into neutral while on a downhill slope...

MPW GCC needs a full MPW environment in order to be used.  Jonathan
Kimmitt has hacked up a standalone version, but it has a number of
limitations (the last time I looked, it couldn't build itself, for
instance).

   Does anyone know why this might be happening, assuming that gcc
   is not buggy. I've tried to inquire with Apple via email, but
   they won't respond. My guess is that, if gcc had been
   executing properly, it simply didn't find any params to work on,
   so it exited.

It's not that "Apple won't respond", it's that there's nobody there
*to* respond.  MPW GCC is not an Apple product, it was a project I
did while in Apple's ATG (and as you might guess from the address below,
I'm no longer there).  If you use it with MPW, it works just fine.

(For those more knowledgeable who might be wondering, yes Cygnus
would be willing to do an updated Mac GCC, *if* appropriate funding
were to be provided - I have no spare time these days :-( )

                            Stan Shebs
                            Cygnus Support
                            [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (John W. Baxter)
Date: Wed, 12 Oct 1994 09:52:59 -0700
Organization: Internet for the Olympic Peninsula

In article <[e-mail]>, [e-mail] (Zack T. Smith)
wrote:

> Hi,
>
> I'd like to find out how I can execute MPW commands without
> having MPW. I know that there is a program available for
> doing this (toolserver), but I don't want to use it.
>
> I notice that the MPW tool that I have (gcc) contains only code
> and version resources. I've tried to execute that as a
> standalone app by changing creator to FNDR and type to APPL,
> but the program immediately exits.

MPW (and ToolServer) provides a considerable amount of environment in
which MPW tools operate.  (Including in MPW's case a "foreign file system"
so that the tool access the current content of a window being edited, when
it thinks it is opening a file by that name.)

What you want to do is not impossible (witness Think/Symantec's SARez and
SADerez, which are apps which provide the needed environment), but more
trouble than it's worth.

   --John

--
John Baxter    Port Ludlow, WA, USA  [West shore, Puget Sound]
   Sorry..I would probably load the resources once, image them into
        offscreen graphics worlds and then just CopyBits in
        DoAnimation. Lots of sample code available to do this BTW.

> Well, the problem is that under a low memory condition (say ~7,000 -
> 8,000 bytes free), the first picture is loaded and displays fine, but
> when the second image is loaded, my app crashes...

        How do you know how much memory you have free?

>
> I then went in and added a
>     ReleaseResource( (Handle )pic);
> This time, each of the four pictures were loaded (and my app didn't crash)

        This should be a clue... (what has changed? why did that
        make a difference?... are your PICT resources marked
        purgeable?)

> ...but when the counter turned back to 0, the first pic wasn't displayed.
>
> I dismissed the dialog box and brought it back up again.  This time, none
> of the pictures were displayed!  Well, this leads me to believe that when
> I call ReleaseResource(), it not only frees up the memory of the handle
> holding the picture, but it clears it from the current resource as well.
> I then tried to use the DisposeHandle() call in place of the
> ReleaseResource() call, and the same thing occurred (all four pictures
> were displayed once and only once).
>
> At this point, I added following:
>
 if (pic != nil) {
       ...
 } else {
>     MoveTo(20, 20);
>     DrawString("\pCan't open image");
> }
>
> the error message never came up!
>
> So what gives?  I can't load and display the image, yet the pic isn't nil
> either!?!?!
>

        There were three statements in that last line.

        1) I can't load the image
        2) I can't display the image
        3) The handle to the image is not nil

        These can not all be true. GetPicture returns nil if it
        was unable to load the image. Since you say "the error
        message never came up" I will assume that 3 is true. This
        means that 1 must be false. This leaves only 2 as a
        problem for your application. This is what you must
        investigate.

        BTW, have you investigated how QuickDraw reports errors.
        Given that it appears that this "feature" is occurring in
        the DrawPicture call, how would you know that it failed?
        Apart from not being able to see the picture.

> Do I need to do a lot of watch dogging and not let any operations be
> performed if the app goes beneath 0k of memory is free?
>

        You have less than 0k of memory free and expect the
        program to do something?

        BTW, just to be a total smart-***, the generally accepted
        way to handle this type of situation is to:

        1) Figure out how much memory you application needs.
        2) Make sure that it gets at least that much.

        ;^) <--- note the smiley!

>
> 3) In Macintosh C Programming Primmer Vol 2, it states that when a
> program starts, it contains a block of master pointers.  It is within
> this location that the location of the Handles are kept (64 of them).  If
> the program requires more than 64, the MoreMasters() call needs to be
> made (which will create 64 more locations for handles).  What happens if
> I have filled up all 64 locations with handles, then create another
> handle (for arguments' sake, let's say that there is enough memory to
> create the size of the handle, and we create a new handle without
> calling MoreMasters())?  Will I run the risk of loosing the handle when
> memory is juggled around?
>

        If you call NewHandle, and you have no more master
        pointers available, NewHandle will call MoreMasters for
        you. The point behind doing it youself is that master
        pointer blocks are non-relocatable and tend to lead to
        heap fragmentation.

        If you let NewHandle make the call, the master pointer
        block will be placed as low in the heap as possible.
        Depending on what you have been doing, you may have
        relocatable or purgeable structures in heap below that
        block. If you want to reuse tpp, if the
memory gets below 10k or 12k, I am going to inform the user that there is
not enough, and that they should close a file.


>>
>> 2) I am loading four separate pictures...
>>
>void DoAnimation(short step) {
>    PicHandle    pic = GetPicture(128+step);
>    if (pic != nil) DrawPicture(pic, &(**pic).portRect);
>}

>>
>> Looks good so far, no?

>        Well, no. I would guess this flashes like mad (but if you
>        haven't gotten it to work yet, you wouldn't know that ;^).
>        I would probably load the resources once, image them into
>        offscreen graphics worlds and then just CopyBits in
>        DoAnimation. Lots of sample code available to do this BTW.

Well, I guess you missed my point.  Yes, the function works
fine (if there is enough memory available).  For right now, I'm not
calling my animation at a set interval, so YES, obviously on faster CPUs it
will be 'FLASHED'.  Yes, I'm am going to put in a timer, so the interval is
standard from one machine to another.

I do know how to use CopyBits and off screen GWorlds.  For this portion
of the code, it is redundant.  Why?  I don't want to permanently 'hold'
the pictures... all I need is one picture drawn to the screen at a time
(therefore, I don't feel I need to hold all four).  Holding the bits in
an offscreen gworld would mean I am using twice the memory for the images:
one for the resource and one for the offscreen memory


>> Well, the problem is that under a low memory condition (say ~7,000 -
>> 8,000 bytes free), the first picture is loaded and displays fine, but
>> when the second image is loaded, my app crashes...

>        How do you know how much memory you have free?

There is a call called FreeMem() which I am using to output the free
memory.  I am also using a utility called SWATCH (System Watch) which
graphically & numerically displays the amount of locked used memory,
moveable used memory, and free memory each app is using.


>>
>> I then went in and added a
>>      ReleaseResource( (Handle )pic);
>> This time, each of the four pictures were loaded (and my app didn't crash)

>        This should be a clue... (what has changed? why did that
>        make a difference?... are your PICT resources marked
>        purgeable?)

Yes, it was a clue.  It was telling me that not only the handle was being
released, but the location of the resource was being released as well.
That is why I was only able to display each image once (and only once).
No, I was not marking the pictures within the resource as being
purgeable, but I am now doing HPurge( (Handle pic ) after the
DrawPicture call... it works..... better, but it still crashes (better in
the sence that if I set my app to run with ~ 12k free and call my dialog
it works, but if memory gets below 6k, it crashes... looks like I will
definately have to work on this a bit.

The point I was trying to make was this:

If I perform a DisposeHandle on a pic handle, how come I am not able to
load and display the picture a second time?  DisposeHandle should just
remove the handle, not the resouce, shouldn't it?

The other point I was trying to make was this:  If I can get the image
(and pic != nil), how come I am not able to display it?  If GetPicture
failed, it's supposed to return a 0, yet it doesn't, so what gives?


>>
>> At this point, I added following:
>>
> if (pic != nil) {
>       ...
> } else {
>>      MoveTo(20, 20);
>>      DrawString("\pCan't open image");
>> }
>>
>> the error message never came up!
>>
>> So what gives?  I can't load and display the image, yet the pic isn't nil
>> either!?!?!
>>

>        There were three statements in that last line.

>        1) I can't load the image
>        2) I can't display the image
>        3) The handle to the image is not nil

>        These can not all be true. GetPicture returns nil if it
>        was unable to load the image. Since you say "the error
>        message never came up" I will assume that 3 is true. This
>        means that 1 must be false. This leaves only 2 as a
>        problem for your application. This  and refer you to further
>        reading, so that you can learn the material yourself and
>        not have to ask again next time.

Pretty close.  I've been programming for several years and have
programmed several different operating systems (Unix, Atari ST/GEM,
Windows, now Mac).  I've been programming the Mac for ~ 6 months in my
spare time.  The biggest problems I have encountered w/the Mac are:

1 Unconventional.  I'm not taliking about event-driven programming
conceps, but things like string types.  Who the hell even USES Str63 or
Str255?!?!???  After years of honning my pointer & string skills, I have
to deal with this junk.  If I write my own function, I use pointers, if I
use a toolbox call, well... I use  StrXXX.  And linked lists... try doing
a linked list on the Mac... I DARE YOU.

2 There are several good Mac programming books out there, but all only
cover the basics.  What I'd like to see is something that covers a full
scale real world type app.  One that covers such topics as Multiple
files/windows opened at a time, localization, printing, error-proofing
apps, etc...  I've seen some books that start to deal with some of these
topics, but don't go into very much depth on them.

3 Example code base is meeger.  There are several areas of Mac programming
which need some indepth examples.  The app which I'm writing shouldn't
have taken this long, but I got locked up on a couple topics.


>        (new) Inside Macintosh: Memory - for references to
>        questions about: MoreMasters, NewHandle, CompactMem,
>        PurgeMem, FreeMem, etc.

Don't have it, but I have THINK Reference.


>        (new) Inside Macintosh: Imaging with QuickDraw - for
>        references to questions about: DrawPicture, GetPicture,
>        etc.


Have it.

>--

>Hope this helps.


a little


Jeff



+++++++++++++++++++++++++++

>From [e-mail] (GBolsinga)
Date: 18 Oct 1994 17:41:08 -0400
Organization: America Online, Inc. (1-800-827-6364)

In article <380uvh$[e-mail]>, [e-mail]
(Jeff Beeghly) writes:

>If I perform a DisposeHandle on a pic handle, how come I am not able to
>load and display the picture a second time?  DisposeHandle should just
>remove the handle, not the resouce, shouldn't it?

This is bad.  Use KillPicture for all PICTs that aren't resources.
Use ReleaseResource for all other PICTs.

Greg
MPI Multimedia


+++++++++++++++++++++++++++

>From [e-mail] (B.J. Buchalter)
Date: Tue, 18 Oct 1994 17:10:45 -0700
Organization: CSU Physics Department

In article <380uvh$[e-mail]>, [e-mail]
(Jeff Beeghly) wrote:


>
> I've received one reply that stated all standard system calls will most
> likely crash when memory gets too low.  Therefore, in my app, if the
> memory gets below 10k or 12k, I am going to inform the user that there is
> not enough, and that they should close a file.
>
>

Yes, this is important. Basically, your strategy needs to be that if the
amount of free memory gets to be too small (e.g. sufficently small that
operations WILL fail), you need to disable all of the commands that will
cause memory to be allocated. That is, if you don;t have enough memory for
the about box, disable the about box command. Similarly, if you are really
low on memory, don't allow the user to open another file, and perhaps ask
them to close one, or ask them to do something else that will free up
memory.


> If I perform a DisposeHandle on a pic handle, how come I am not able to
> load and display the picture a second time?  DisposeHandle should just
> remove the handle, not the resouce, shouldn't it?

You definitely do not want to use DisposeHandle on a resource. The
Resource Manager keeps a table of which resources are loaded and where
they are in memory. The Memory Manager keeps a table(s) of which handles
are allocated and where they are in memory. If you tell the resource
manager to release the resource it cleans up its table and marks the
resource purgable. If you tell the memory manager to Dispose the handle,
here either wasn't enough memory to load the resource, or the resource
was purged.  If the first dereference is NULL, call LoadResource to see
if you can load it.  Code that I use for loading any handle looks like
this:

    Handle h = GetResource('XXXX', id);

    if (h)            // resource exists?
    {
        if (!*h)
            LoadResource(h);

        if (*h)
        {
            // use the resource
        }

        ReleaseResource(h);            // or HPurge(h) is
even better!
    }

>The biggest problems I have encountered w/the Mac are:
>
>1 Unconventional.  I'm not taliking about event-driven programming
>conceps, but things like string types.  Who the hell even USES Str63 or
>Str255?!?!???  After years of honning my pointer & string skills, I have
>to deal with this junk.  If I write my own function, I use pointers, if I
>use a toolbox call, well... I use  StrXXX.  And linked lists... try doing
>a linked list on the Mac... I DARE YOU.

No problem.  I use linked lists all the time.  Pointer AND Handles.

>2 There are several good Mac programming books out there, but all only
>cover the basics.  What I'd like to see is something that covers a full
>scale real world type app.  One that covers such topics as Multiple
>files/windows opened at a time, localization, printing, error-proofing
>apps, etc...  I've seen some books that start to deal with some of these
>topics, but don't go into very much depth on them.

I agree.  I've been thinking about that one for a while.  Especially
printing.  Printing is *EASY* on the Mac.  Try writing a simple printable
app for Windows -- what a NIGHTMARE!  For example, under Windows, you
have to do your own scaling (Move and Line are
device-resolution-specific, but Ellipse and such are based upon the
current scaling factor set).  I also found a major bug in printing
landscape (on an HP PCL printer) -- the same code which worked correctly
when printing portrait broke badly when printing landscape.  Items were
moved, portions of graphic items were drawn in different places on the
page (for example, half of an ellipse was drawn in one spot, the other
half was drawn in another spot, and there was white space between the two
halves!).  I ended up writing my own landscape code, and letting the
print drivers (plural -- each printer does its own print code) tell me
whether I should do my landscaping code.  That bug alone took two months
to find, diagnose and fix, because, although you can rotate text, many of
the parts of Windows GDI break down when dealing with vertical rather
than horizontal text.

>3 Example code base is meeger.  There are several areas of Mac
programming
>which need some indepth examples.  The app which I'm writing shouldn't
>have taken this long, but I got locked up on a couple topics.

I definately agree on this one, especially some of the newer managers!
However, many of the newer managers (that are extensive, like AOCE or
QDGX) have many example programs to search through to find the answers to
many questions.

However, it has been my experience that Windows programming examples are
even scarcer -- I had to find PD applications which addressed some of the
same issues I had to deal with!  Microsoft basically doesn't provide
anything easily accessable, and although Borland did provide some sample
code with their compiler, most of it had to do with the "bells &
whistles" of Windows, like OLE, MCI, and so forth, but very little on
standard "how to display a window contents and deal with scroll bars."  I
basically had to experiment with that until I got it right -- another two
months down the drain.

The same basic program that I wrote under Windows which took 12 months to
write and debug took 1 weekend (that's less than 40 hrs, folks!) to write
using Symantec C++ and TCL.  Much of the stuff I got for free on the
Macintosh.  Much of the stuff I had to write under Windows...
//
// Glenn L. Austin
// Computer Wizard and Racing Car Driver
// Internet:  [e-mail]
//

+++++++++++++++++++++++++++

>From [e-mail] (Brian Stern)
Date: 19 Oct 1994 17:25:21 GMT
Organization: The University of Texas at Austin, Austin, Texas

In article <380uvh$[e-mail]>, [e-mail]
(Jeff Beeghly) wrote:

<
<
< >> Do I need to do a lot of watch dogging and not let any operations be
< >> performed if the app goes beneath 0k of memory is free?
< >        You have less than 0k of memory free and expect the
< >        program to do something?
<
< That was a typo.  It should have been 10k free.
<
< >        BTW, just to be a total smart-***, the generally accepted
< >        way to handle this type of situation is to:
<
< >        1) Figure out how much memory you application needs.
< >        2) Make sure that it gets at least that much.
<
< >        ;^) <--- note the smiley!
<
< Yep.  Verry standard.  But the problem is this:  My app will handle an
< unlimited number of files/windows (memory permitting).  I do not wish to
< limit the user by only allowing them a max number of files open at a time
< (like 5 or 10).  Each window/file at it's maximum will use ~ 55 handles
< (I'm displaing a max of 50 icons, each is contained within an IconSuite,
< which is a handle).  If I plan on having 5 files open, I should probably
< call MoreMasters 4 times.  If I plan on having 10 files open, I should
< probably call MoreMasters 9 times.
<
< Get my point?
<
< It's varriable depending on the user.  Ideally it would be nice to Call a
< MoreMasters() call before I open a file, then do a DeleteMoreMasters call
< (if such a call had existed) after I calosed a file.  These are all
< design issues I will have to iron out I guess.
<
<

Most of the sample code I've seen uses a size of about 40K as the time to
post a low memory warning.  Since we're talking about 'Real World' apps
you should know that ALL real world apps have a growZone procedure and use
some mechanism for keeping a buffer of memory available.  Usually this
done by a mechanism known as the rainy-day fund.  Briefly, at app startup
you allocate a handle of, say, 40K.  That's your rainy day fund.  Each
time through your main event loop ( or perhaps only on null events) you
check the available memory.  If it's too low you post a warning alert.
Under some circumstances you release the rainy day handle.  Either from
your growZone Proc or possibly in response to an explicit call from
somewhere in your app.

Regarding the MoreMasters calls.  Exercise your app thoroughly with a
number of windows/documents open that is on the high side of what you
would consider avaerage.  See how many Master Pointer blocks were needed.
Maybe add 2 or 3 to this number and call MoreMasters this many times.
Eight or ten should be more than sufficient.  Realize that any user that
sees the 'not enough memory' warning is going to up the partition size for
the app.  Although this doesn't automatically increase the number of
Master Pointer blocks it does give the app more breathing room so that if
any are automatically allocated any problems caused by heap fragmentation
are minimized.  The important thing is to warn when memory gets low.


<   The biggest problems I have encountered w/the Mac are:
<
< 1 Unconventional.  I'm not taliking about event-driven programming
< conceps, but things like string types.  Who the hell even USES Str63 or
< Str255?!?!???  After years of honning my pointer & string skills, I have
< to deal with this junk.  If I write my own function, I use pointers, if I
< use a toolbox call, well... I use  StrXXX.  And linked lists... try doing
< a linked list on the Mac... I DARE YOU.

Gee Jeff, we were just beginning to like you, and then you turn on us like
this:)  Are you aware that your windowlist is a linked list?  There are
numerous operating system queues that are linked lists.  Doing linked
lists with memory allocated by NewPtr or by malloc is no different than on
any other architecture.  You can do linked lists with handles.  The only
difference is an extra * here or there when referring to the memory
blocks.

If you're not aware, the reason for the Str255 and friends string types
are due to the Mac's Pascal heritage.  Don't complain about it, just
accept it.  Every development environment has utility routines to
translate between C and P strings.  Sorry you had to learn something new.

<
< 2 There are several good Mac programming books out there, but all only
< cover the basics.  What I'd like to see is something that covers a full
< scale real world type app.  One that covers such topics as Multiple
< files/windows opened at a time, localization, printing, error-proofing
< apps, etc...  I've seen some books that start to deal with some of these
< topics, but don't go into very much depth on them.
<
< 3 Example code base is meeger.  There are several areas of Mac programming
< which need some indepth examples.  The app which I'm writing shouldn't
< have taken this long, but I got locked up on a couple topics.

Are you aware of the sample code at ftp.apple.com and at the
alt.sources.mac archive at ftp://ftpbio.bgsu.edu/?

<
<
<
< Have it.
<
< >--
<
< >Hope this helps.
<
<
< a little
<
<
< Jeff

Good luck,

--
Brian  Stern  :-{)}
Toolbox commando and Menu bard
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Ari I Halberstadt)
Date: Thu, 20 Oct 1994 04:00:28 GMT
Organization: The World Public Access UNIX, Brookline, MA

In article <[e-mail]>,
Brian Stern <[e-mail]> wrote:
>In article <380uvh$[e-mail]>, [e-mail]
>(Jeff Beeghly) wrote:
>
><
><
>< >> Do I need to do a lot of watch dogging and not let any operations be
>< >> performed if the app goes beneath 0k of memory is free?
>...
>< Get my point?

Get ZoneRanger and a color monitor. This is the *coolest* free program
for figuring out what the heck your app is doing in its memory
partition. It should be on any archive site and plenty of CDs.
Also, get ProcessWatcher, another free and useful tool.

>Most of the sample code I've seen uses a size of about 40K as the time to
>post a low memory warning.  Since we're talking about 'Real World' apps
>you should know that ALL real world apps have a growZone procedure and use
>some mechanism for keeping a buffer of memory available.  Usually this
>done by a mechanism known as the rainy-day fund.  Briefly, at app startup
>you allocate a handle of, say, 40K.  That's your rainy day fund.  Each
>time through your main event loop ( or perhaps only on null events) you
>check the available memory.  If it's too low you post a warning alert.
>Under some circumstances you release the rainy day handle.  Either from
>your growZone Proc or possibly in response to an explicit call from
>somewhere in your app.

I've abstracted and elaborated this. Each level in an app gets a
reserve memory. Then there's a memory cushion in addition. The app
sets the allocation level. The Toolbox level is the lowest, since the
TB can crash if it doesn't get memory. When I need to allocate memory,
I bump up the level, then restore it afterwards. For critical things,
like quitting and saving a file, I bump up the memory to a "critical"
level. Each level allows access to different memory reserves. The size
of the memory reserves for each level is set in a configuration
resource. The grow zone function runs a loop in which it frees up
reserves (depending on the current level) until enough bytes have been
freed. Memory warnings are issued depending on how much of the
reserves are depleted and how little memory is left. At each warning
level, the application can take different actions, e.g., at first just
an alert, then disabling functions like undo, then automatically
asking the user to close files, then automatically closing unmodified
files and saving modified files to temporary locations, and, finally,
terminating the application if all of the reserves are depleted and
there is very little memory left (e.g., less than 10K). I also have
code to automatically unload inactive segments, but it's not very
portable (works only with THINK C, not with Metrowerks).

>...
>< 1 Unconventional.  I'm not taliking about event-driven programming
>< conceps, but things like string types.  Who the hell even USES s for most operations because I always have
the length available without worrying about caching the result of
'strlen'. The fact that there are a zillion 'Str...' shouldn't faze you;
they're just Pascal strings with different maximum sizes. I use 'Str15',
for example, all the time for quick calls to 'NumToString'.

> And linked lists... try doing
> a linked list on the Mac... I DARE YOU.

I have. Other posters have pointed out that handles on the Macintosh are
not the same as handles on Windows. There's no more difficulty in writing
linked list code on the Mac than there is in typing an extra '*'. (It's
when people start trying to optimize the double-dereferencing that they
get into trouble.)

> 3 Example code base is meeger.  There are several areas of Mac programming
> which need some indepth examples.  The app which I'm writing shouldn't
> have taken this long, but I got locked up on a couple topics.

This is an odd observation, given that you appear to have "real" internet
access. Perhaps you are unaware of the many 'ftp' archive sites. There is
also copious example code on the various CD ROMs produced by Apple.

> >        (new) Inside Macintosh: Memory - for references to
> >        questions about: MoreMasters, NewHandle, CompactMem,
> >        PurgeMem, FreeMem, etc.
>
> Don't have it, but I have THINK Reference.

You absitively posolutely need to buy the relevant Inside Macintosh
volumes. They cost a lot of money. You need to buy them anyway.

--
 Views expressed here do not necessarily reflect the views of Novell.

---------------------------

>From [e-mail] (Peter Hull)
Subject: NewGWorld returns null pointer
Date: 20 Oct 1994 09:24:21 GMT
Organization: CRL Dialup Internet Access    [phone]  [Login:
guest]

Hello,

I have a problem related to using GWorlds-- NewGWorld returns null in the
GWorld pointer.  I am using TCL 1.1.3.  When the problem occurs, I already
have one document object open, identical to the one I am trying to create.
If I close the first document and then open a second one, everything is
cool.  But if I try to open a second document while the first is still open,
when my CGWorld object calls NewGWorld to create the offscreen world, it
gets this null pointer.  I am running the program in 4 megs of memory,
and the images are only 256x256 pixels.  (I'm using the Pico sample images
from 'develop' #10, from 'develop' CD #19.)

Does anybody have any idea why NewGWorld would return a null GWorld?  There's
nothing in Inside Macintosh that would suggest that NewGWorld might return
a null pointer except for the example code in NIM: "Imaging with QuickDraw",
chapter 6, which tests for a null pointer.  That is where I got the idea that
that might be the problem.  (Originally I thought the problem might be with
DrawPicture, because that's where the program froze.)

Any help would be appreciated...

Thanks in advance!

--
--
Peter Hull <[e-mail]>

+++++++++++++++++++++++++++

>From [e-mail] (Peter Hull)
Date: 20 Oct 1994 21:18:34 GMT
Organization: CRL Dialup Internet Access    [phone]  [Login:
guest]

Peter Hull ([e-mail]) wrote:
: Hello,

: I have a problem related to using GWorlds-- NewGWorld returns null in the
: GWorld pointer.  I am using TCL 1.1.3.  When the problem occurs, I already
: have one document object open, identical to the one I am trying to create.
: If I close the first document and then open a second one, everything is
: cool.  But if I try to open a second document while the first is still
open,
: when my CGWorld object calls NewGWorld to create the offscreen world, it
: gets this null pointer.  I am running the program in 4 megs of memory,
: and the images are only 256x256 pixels.  (I'm using the Pico sample images
: from 'develop' #10, from 'develop' CD #19.)

: Does anybody have any idea why NewGWorld would return a null GWorld?
There's
: nothing in Inside Macintosh that would suggest that NewGWorld might return
: a null pointer except for the example code in NIM: "Imaging with
QuickDraw",
: chapter 6, which tests for a null pointer.  That is where I got the idea
that
: that might be the problem.  (Originally I thought the problem might be with
: DrawPicture, because that's where the program froze.)

I now have discovered that the problem occurs also on the first document
object sometimes.  Why this is I still have no idea.  Here is the call,
straight from my source code:

    FailOSErr(anErr = NewGWorld(&itsWorld, depth,
                  &boundsRect, NULL, NULL, 0));

'boundsRect' is { 0, 0, 256, 256 }, 'depth' is 16.

After the call, sometimes 'itsWorld' is NULL.

However, I have never had an error show up in 'anErr'.
Any ideas?

--
--
Peter Hull <[e-mail]>

+++++++++++++++++++++++++++

>From [e-mail] (Brian Stern)
Date: 23 Oct 1994 18:07:12 GMT
Organization: The University of Texas at Austin, Austin, Texas

In article <386mra$[e-mail]>, [e-mail] (Peter Hull) wrote:

< Peter Hull ([e-mail]) wrote:
< : Hello,
<
< : I have a problem related to using GWorlds-- NewGWorld returns null in the
< : GWorld pointer.  I am using TCL 1.1.3.  When the problem occurs, I
already
<
<         FailOSErr(anErr = NewGWorld(&itsWorld, depth,
<                   &boundsRect, NULL, NULL, 0));
<
< 'boundsRect' is { 0, 0, 256, 256 }, 'depth' is 16.
<
< After the call, sometimes 'itsWorld' is NULL.
<
< However, I have never had an error show up in 'anErr'.
< Any ideas?
<
< --
< --
< Peter Hull <[e-mail]>

Actually this very question was posted a month or so back.  Are you
locking the object before making this call?  NewGWorld moves memory.  TCL
1.1.3 objects are handles.  If itsWorld is an instance varible and the
object is unlocked then NewGWorld will succeed but &itsWorld won't point
to the object anymore.  Either lock the object, or use a local varible for
the first parameter to NewGWorld and  then set itsWorld from the local
variable.

Good luck,

--
Brian  Stern  :-{)}
Toolbox commando and Menu bard
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Peter Hull)
Date: 24 Oct 1994 10:16:33 GMT
Organization: CRL Dialup Internet Access    [phone]  [login:
guest]

Regarding the GWorld problem with NewGWorld returning a null pointer,
Brian Stern's solution was correct.  He suggested that the problem was
being caused by NewGWorld moving memory while the object that called
it was unlocked in the heap.  This caused the (handle-based) object to
not receive the pointer correctly.  Here is my implementation of the fix:

HLock ((Handle) this);

<NewGWorld call here>

HUnlock ((Handle) this);

Depressingly simple, isn't it?  Many thanks to Brian and also to
Francois Pottier who e-mailed me with the same solution.

Cheers,

Peter

--

Peter Hull
<[e-mail]>

---------------------------

>From mclow@san_marcos.csusm.edu (Marshall Clow)
Subject: Pathnames? I don't think so...
Date: Fri, 14 Oct 1994 17:36:29 -0700
Organization: Aladdin Systems

In article <[e-mail]>,
[e-mail] wrote:

> Not to answer the question, but to advance it to a different level, when
you
> do a call to FindFolder (let's say to find the preferences folder on the
> startup volume) and you get a Folder ID, what is the most efficient way to
> convert it or utilize the information to be a path?
>
> Just another newbie,

OK. Here we go:
   On the mac, in general, you don't want to use pathnames. Users have
this distressing habit of moving files and renaming folders.

To open/rename/delete/etc a file:
   All the appropriate routines take a triplet:
      volume, directory ID, and file name.
In your example, you already have a volume refnum, and directory ID,
(from your call to FindFolder), and presumably you have the name.
   err = HOpen ( vrefNum, dirID, fName, fsRdWrPerm, &refNum );


To save the location of a file so you can find it later:
   Use the alias manager.

NewAlias (...);
later: ResolveAlias ( ... );

--
Marshall Clow
Aladdin Systems
mclow@san_marcos.csusm.edu


---------------------------

>From [e-mail] (Bob Bradley)
Subject: Q: Creating Variable sized structures?
Date: Sun, 16 Oct 1994 09:26:42 -0800
Organization: SS Software Inc.

How do you create variable sized structures, similar to how DITL resources
are used by the Dialog Manager?

Do they just create a handle and tack on things as they go? If so, it
would seem like they'd need some sort of index or they'd have to parse the
list each time to access individual items.

I'm writing a View-like library for creating Windows/Dialogs and I'm
looking for a good way to create variable sized structures that define the
details of the View but, having a tough time with this part of it.

Any comments appreciated.

+++++++++++++++++++++++++++

>From Eric Kidd <[e-mail]>
Date: 18 Oct 1994 03:00:39 GMT
Organization: Dartmouth College

Q: Creating Variable sized structures?

One easy way to do this is--if the variable part of the record is of
constant
size--is to define a struct like:

typedef struct
{
   // header info

   short index;
   element_type element[1];
} myType;

Reference data of this type with a handle and use the memory manager
(ResizeHandle? SizeHandle? I forget at the moment.) to resize it as you
need. You
could write a routine:

   ResizeMyType( myType** theData, short numSlots )

and call it as needed. Hope this helps. Any feedback appreciated.

+++++++++++++++++++++++++++

>From [e-mail] (Brian Stern)
Date: 18 Oct 1994 06:52:05 GMT
Organization: The University of Texas at Austin, Austin, Texas

In article <[e-mail]>, [e-mail]
(Bob Bradley) wrote:

< How do you create variable sized structures, similar to how DITL resources
< are used by the Dialog Manager?
<
< Do they just create a handle and tack on things as they go? If so, it
< would seem like they'd need some sort of index or they'd have to parse the
< list each time to access individual items.
<
< I'm writing a View-like library for creating Windows/Dialogs and I'm
< looking for a good way to create variable sized structures that define the
< details of the View but, having a tough time with this part of it.
<
< Any comments appreciated.

Yes, variable-sized resources are built by allocating a handle and then
tacking things onto the end of it.  The routines like GetDItem, SetDItem,
and GetIndString walk down the resource each time to find the particular
item's data.  In general these data structures are small so that finding
the third or tenth item doesn't take very long.  Finding the hundreth or
thousandth item this way would be very slow.

Each of the items in these variable length data structures has a length
byte or short that is at a fixed offset from the beginning of each item
(often the offset is zero) to facilitate walking down the structure.  Also
the resource has an entry count in it, usually at the beginning.  Adding a
new item at the end is just a matter of using PtrAndHand and then updating
the item counter.  Modifying existing items or inserting items in the
middle is a matter of adjusting the size of the handle and blockmove to
make space in the middle, followed by blockmove to insert the new data.

My personal favorite is the Speech Manager 'dict' resource.  In this
perverse resource there is a header, followed by a variable length array
of variable length records.  Each of these last records consists of two
(or more) variable length records.  Sort of like an array of STR#
resources.

--
Brian  Stern  :-{)}
Toolbox commando and Menu bard
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Christopher Larson)
Date: 18 Oct 1994 16:51:27 GMT
Organization: UCLA, Computer Science Department

In article <37vdon$[e-mail]> Eric Kidd <[e-mail]>
writes:
>Q: Creating Variable sized structures?
>
>One easy way to do this is--if the variable part of the record is of
>constant
>size--is to define a struct like:
>
>typedef struct
>{
>   // header info
>
>   short index;
>   element_type element[1];
>} myType;

In THINK C (don't know about CW) it is legal to declare an array of
unspecified
size (e.g. "element_type element[];") which will not contribute to the size
of
the struct.:05:00 GMT
Organization: Dept. of Computer Science, Concordia University

In article <380ppq$[e-mail]>, [e-mail] (Eric
Bennett) writes:
|> I have successfully used PBSetVInfo to software-lock a volume as
|> described in Inside Mac: Files on page 2-147, which deals with
|> PBSetVInfo (call PBGetVInfo, set bit 15 of the ioVAtrb field, and call
|> PBSetVInfo).  The only problem is that I cannot UNLOCK these volumes
|> using the same method (this time clearing bit 15)--I get the error
|> "volume locked" (error -43, I think). Yes, the volume is locked, but
|> shouldn't the command which can set the lock be able to unlock it?
|> What toolbox call CAN I use to unlock a software-locked volume?
|>
|> Thanks,
|> [e-mail]



I will help you !
I have made a soft called DiskLocker that made what you want.
Before unlocking the disk with PBSetVInfo, you must update a global variable
used by the Finder. I do not remember its name and its structure but I will
check at home and I will reply to you again soon.


olivier lebra      [e-mail]  or [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Steve Bryan)
Date: Fri, 21 Oct 1994 06:24:29 GMT
Organization: Sexton Software

> In article <380ppq$[e-mail]>, [e-mail]
> (Eric Bennett) wrote:
>
>  Yes, the volume is locked, but
> > shouldn't the command which can set the lock be able to unlock it?
> > What toolbox call CAN I use to unlock a software-locked volume?
>

I don't know if you already have the response but the trick is to update
the vcb queue elem before making the unlock toolbox call. You can get the
vcb queue elem either by "walking the vcb queue" and setting the
appropriate bit in place (I think it is one of the bits in the attribute
field) or make a couple of calls to PBGetVInfo and PBSetVInfo. This
strategy worked for a little control panel I wrote many years ago (ie the
source code is not handy). Good luck.

--
Steve Bryan                  InterNet: [e-mail]
Sexton Software            CompuServe: 76545,527
Minneapolis, MN                   Fax: [phone]

+++++++++++++++++++++++++++

>From [e-mail] (LEBRA olivier)
Date: 21 Oct 1994 19:08:39 GMT
Organization: Dept. of Computer Science, Concordia University

In article <[e-mail]>,
[e-mail] (Steve Bryan) writes:
|> > In article <380ppq$[e-mail]>, [e-mail]
|> > (Eric Bennett) wrote:
|> >
|> >  Yes, the volume is locked, but
|> > > shouldn't the command which can set the lock be able to unlock it?
|> > > What toolbox call CAN I use to unlock a software-locked volume?
|> >
|>
|> I don't know if you already have the response but the trick is to update
|> the vcb queue elem before making the unlock toolbox call. You can get the
|> vcb queue elem either by "walking the vcb queue" and setting the
|> appropriate bit in place (I think it is one of the bits in the attribute
|> field) or make a couple of calls to PBGetVInfo and PBSetVInfo. This
|> strategy worked for a little control panel I wrote many years ago (ie the
|> source code is not handy). Good luck.
|>
|> --
|> Steve Bryan                  InterNet: [e-mail]
|> Sexton Software            CompuServe: 76545,527
|> Minneapolis, MN                   Fax: [phone]


I think the simplest way to update the vcb queue is :
DefVCBPtr->vcbAtrb &= 0x7FFF;


--
*********************************************************************
*        olivier       * Until July 1996 : [e-mail] *
*         lebra        * Until May 1995  : [e-mail]    *
*********************************************************************
* 1950, Lincoln  App #1707  -  H3H 2N8  Montreal, Quebec  -  CANADA *
* Phone : [phone]                                         *
*********************************************************************
*     "La simplicite est l'ultime forme de la sophistication."      *
*********************************************************************

+++++++++++++++++++++++++++

>From [e-mail] (Eric Bennett)
Date: 24 Oct 1994 16:18:11 GMT
Organization: Penn State University

In article <[e-mail]>
[e-mail] (Kluev) writes:

> Try clear locked flag of vcbAtrb field of VCB describing volume.
> You can find VCB using GetVCBQHdr call and stepping via dLink
> field until you find the volume. This method, however, should
> be treated as modifying internal File Manager structures and
> should be avoided if possible.

I know--Inside Mac says DON'T PLAY WITH THE VCB--it is supposed to be
read only, not written to.  My question was, if I'm not supposed to
modify the VCB, how do I unlock the volume?  (Incidentally, when I
tried modifying the VCB, my machine locked up; however, since that's
the only suggestion I've gotten, I guess I'll try doing it again :).

[e-mail]

---------------------------

>From [e-mail] (Anton Rang)
Subject: Some string routines for the PowerPC
Date: 15 Oct 1994 21:29:50 GMT
Organization: Trillium Research, Inc.

Archive-name: ppc-string-utils.txt
Submitted-by: [e-mail]

This file implements some basic string routines for both C and Pascal
strings.  It's written in PowerPC assembly.  I did this mainly as a
learning experience; I was bored one day, and wanted to play with the
string instructions.

Routines implemented here are:

  strcpy and strcat -- both of these are about 30% faster than those
               provided by Apple or Metrowerks.

  pstrcpy and pstrcat -- very fast versions of the above for use with
             Pascal-style strings; much faster than those
             provided by Apple (PLstrcpy/PLstrcat).

  pstreq -- a fast equality test for Pascal-style strings.

If there's interest, I may develop and post more of these later.

I've appended a binhexed object library for those without an assembler.

An open question: Is there interest in developing a complete, or at
least subset, copyright-free, optimized, ANSI library for the PowerPC?
I see people complaining about Metrowerks' implementation, and neither
Metrowerks nor Apple has so far released a highly optimized library.
I'd rather see them concentrating on compiler technology, anyway.  If
there's enough interest, surely those of us on the net could compile a
reasonably complete library.  This would surely benefit all of the Mac
community.

  -- Anton

- -------- mylib.s
;
; Anton's library of handy string routines and such.
;

;
; char *strcpy(char *, const char *)
;
; Copy a null-terminated string from one location to another; return the
first location.
; This goes really fast if you use the POWER 'lscbx' instruction.  *sigh*
;

        export  my_strcpy[DS]
        export  .my_strcpy[PR]

        toc
            tc  my_strcpy[TC], my_strcpy[DS]

        csect   my_strcpy[DS]
            dc.l    .my_strcpy[PR]
            dc.l    TOC[tc0]
            dc.l    0

        csect   .my_strcpy[PR]

        ; First, move R3 into R5, so we have a copy we can change.  Bias it
down by one byte.
        ; Bias R4 down too.

        subi    r5, r3, 1
        subi    r4, r4, 1

        ; Read a byte, store it, and compare it against zero.  Loop until we
find the zero.
        ; By issuing the compare before the store, we save one cycle in
branch resolution.

@0:     lbzu    r0, 1(r4)
        cmpwi   r0, 0
        stbu    r0, 1(r5)
        bne     @0

        ; All done.  Note that R3 has the return value already.

        blr

;
; void pstrcpy(unsigned char *, const unsigned char *)
;
; Copy a byte-counted string from one location to another.
;

        export  pstrcpy[DS]
        export  .pstrcpy[PR]

        toc
            tc  pstrcpy[TC], pstrcpy[DS]

        csect   pstrcpy[DS]
            dc.l    .pstrcpy[PR]
            dc.l    TOC[tc0]
            dc.l    0

        csect   .pstrcpy[PR]

        ; Get the byte count, and add one to it to include the length byte.

        lbz     r5, 0(r4)
        addi    r5, r5, 1

        ; If the length is <= 32, we can complete the move in one pass.  We
assume that this
        ; is the most common case, and hence set the branch-predict bit here.
        ; (Why 32 bytes?  We have 8 non-volatile scratch registers, R5..R12,
to use.)

@0:     cmpwi   r5, 32
        ble+    @1

        ; OK...more than 32 bytes to move.  We'll move 28 bytes and then see
if we can finish.
        ; (Why 28 bytes?  We're holding the length in R5, so we only have 7
scratch registers.)

        subi    r5, r5, 28

        lswi    r6, r4, 28
        addi    r4, r4, 28

        stswi   r6, r3, 28
        addi    r3, r3, 28

        b       @0

        ; We complete the move here, mov    b       @0

        ; We complete the move here, moving between 1 and 32 bytes.

@1:     mtxer   r5

        lswx    r5, r0, r4
        stswx   r5, r0, r3

        blr

;
; char *strcat(char *, const char *)
;
; Concatenate a null-terminated string onto another; return the address of
the first string.
;

        export  my_strcat[DS]
        export  .my_strcat[PR]

        toc
            tc  my_strcat[TC], my_strcat[DS]

        csect   my_strcat[DS]
            dc.l    .my_strcat[PR]
            dc.l    TOC[tc0]
            dc.l    0

        csect   .my_strcat[PR]

        ; First, move R3 into R5, so we have a copy we can change.  Bias it
down by one byte.
        ; Bias R4 down too.

        subi    r5, r3, 1
        subi    r4, r4, 1

        ; Walk down the first string to its end.

@0:     lbzu    r0, 1(r5)
        cmpwi   r0, 0
        bne     @0

        ; R5 is now one byte past the end of the string.  Go backwards to
bytes, so that
        ; it points just before the end of the string.

        subi    r5, r5, 2

        ; Read a byte, store it, and compare it against zero.  Loop until we
find the zero.
        ; By issuing the compare before the store, we save one cycle in
branch resolution.

@1:     lbzu    r0, 1(r4)
        cmpwi   r0, 0
        stbu    r0, 1(r5)
        bne     @1

        ; All done.  Note that R3 has the return value already.

        blr

;
; void pstrcat(unsigned char *, const unsigned char *)
;
; Concatenate a byte-counted string onto another.  This doesn't do any error
checking.
;

        export  pstrcat[DS]
        export  .pstrcat[PR]

        toc
            tc  pstrcat[TC], pstrcat[DS]

        csect   pstrcat[DS]
            dc.l    .pstrcat[PR]
            dc.l    TOC[tc0]
            dc.l    0

        csect   .pstrcat[PR]

        ; Get the byte count of both strings.

        lbz     r6, 0(r3)
        lbz     r5, 0(r4)

        ; Note that lswx/stswx are defined to do nothing if the length (in
XER) is zero.
        ; If they weren't, we would want the following two lines, to check
that the
        ; concatenation is actually doing something.

        ; cmpwi r5, 0
        ; beqlr

        ; Add them together to get the new length; store it.

        add     r7, r6, r5
        stb     r7, 0(r3)

        ; Move destination address past old data (length + 1 bytes).
        ; Move source address past its length too (1 byte).

        addi    r3, r3, 1
        addi    r4, r4, 1
        add     r3, r3, r6

        ; If the length is <= 32, we can complete the move in one pass.  We
assume that this
        ; is the most common case, and hence set the branch-predict bit here.
        ; (Why 32 bytes?  We have 8 non-volatile scratch registers, R5..R12,
to use.)

@0:     cmpwi   r5, 32
        ble+    @1

        ; OK...more than 32 bytes to move.  We'll move 28 bytes and then see
if we can finish.
        ; (Why 28 bytes?  We're holding the length in R5, so we only have 7
scratch registers.)

        subi    r5, r5, 28

        lswi    r6, r4, 28
        addi    r4, r4, 28

        stswi   r6, r3, 28
        addi    r3, r3, 28

        b       @0

        ; We complete the move here, moving between 1 and 32 bytes.

@1:     mtxer   r5

        lswx    r5, r0, r4
        stswx   r5, r0, r3

        blr

;
; void pstrcatchr(unsigned char *dest, unsigned char src)
;
; Concatenate a single character onto a byte-counted string.
;

        export  pstrcatchr[DS]
        export  .pstrcatchr[PR]

        toc
            tc  pstrcatchr[TC], pstrcatchr[DS]

        csect   pstrcatchr[DS]
            dc.l    .pstrcatchr[PR]
            dc.l    TOC[tc0]
            dc.l    0

        csect   .pstrcatchr[PR]

        ; Get the byte count of the string; add one to it and store it back.

        lbz     r5, 0(r3)
        addi    r5, r5, 1
        stb     r5, 0(r3)

        ; Store the character we want to concatenate at the end of the
string, and return.

        stbx    r4, r3, r5
        blr

;
; Boolean pstreq(unsigned char *s1, unsigned char *s2)
;
; Compare two byte-counted strings for equality; return true (1) if they're
equal.
;

        export  pstreq[DS]
        export  .pstreq[PR]

        toc
            tc  pstreq[TC], pstreq[DS]

        csect   pstreq[DS]
            dc.l    .pstreq[PR]
            dc.l    TOC[tc0]
            dc.l    0

        csect   .pstreq[PR]

        ; First, get the byte count of both strings.

        lbz     r5, 0(r3)
        lbz     r6, 0(r4)

        ; If the byte counts aren't equal, fail immediately.

        cmpw    r5, r6
        bne     @fail

        ; OK, we have two strings of matching length.  Increment the
addresses to point to
        ; the actual text of the strings.

        addi    r3, r3, 1
        addi    r4, r4, 1

        ; If the length is <= 16, we can complete the comparison in one pass.
We assume
        ; that this is the most common case, and hence set the branch-predict
bit here.
        ; (Why 16 bytes?  We have 8 non-volatile scratch registers, R5..R12,
to use.)

@0:     cmpwi   r5, 16
        ble+    @1

        ; OK...more than 16 bytes to compare.  We'll compare 12 bytes and
then see if we can
        ; finish.  (Why 12 bytes?  The length is in R5, so we only have 7
scratch registers,
        ; and we can only use whole registers for the string-load
instructions.)

        lswi    r6, r3, 12
        lswi    r9, r4, 12

        addi    r3, r3, 12
        addi    r4, r4, 12
        subi    r5, r5, 12

        ; Compare each of the register pairs R6/R9, R7/R10, R8/R11.  If any
differs, exit.

        cmp     0, 0, r6, r9
        cmp     1, 0, r7, r10
        cmp     2, 0, r8, r11

        bne     0, @fail
        bne     1, @fail
        bne     2, @fail

        b       @0

        ; We complete the comparison here, comparing between 1 and 16 bytes.
        ; If R5 is zero, we succeed immediately.

@1:     cmpwi   r5, 0
        beq     @succ

        ; Load the strings into R5..R8 and R9..R12.  Save R5 first.

        mr      r0, r5
        mtxer   r5

        lswx    r5, r0, r3
        lswx    r9, r0, r4

        ; Compare R5 against R9; if they differ, fail.
        ; If they're the same, and R0 is <= 4, succeed.

        cmp     0, 0, r5, r9
        cmpi    1, 0, r0, 4

        bne     0, @fail
        ble     1, @succ

        ; Compare R6 against R10; fail if different.  Succeed if R0 <= 8.

        cmp     0, 0, r6, r10
        cmpi    1, 0, r0, 8

        bne     0, @fail
        ble     1, @succ

        ; Compare R7 against R11; fail if different.  Succeed if R0 <= 12.

        cmp     0, 0, r7, r11
        cmpi    1, 0, r0, 12

        bne     0, @fail
        ble     1, @succ

        ; compare R8 against R12; fail if different, succeed if same.

        cmpw    r7, r11
        bne     @fail

        ; Success!

@succ:  li      r3, 1
        blr

        ; Failure

@fail:  li      r3, 0
        blr

- ----- mylib.s.o.hqx

--
Anton Rang ([e-mail])

---------------------------

>From [e-mail] (Brian Bechtel)
Subject: Tech Notes on the World Wide Web, and History Is Made
Date: 19 Oct 1994 16:49:23 -0700
Organization: Apple Computer, Inc., Cupertino, California

New excitement on the digital traffic jam.

Apple has now put all the tech notes (including the four new technotes
from the November developer CD which is _just_ going into the mail to
our developers right now as I type) on the Web.  Use Mosaic. Use MacWeb.
Use NetScape.  Explore.

 http://www.info.apple.com/dev/technotes/Main.html

The new tech notes include Jim Luther's "FL 37 Permission to do
What?!!?" (file permissions), Nitin Ganatra's "PS 02 Background-Only
Applications" (a revision of how to write faceless background
applications), Brian Bechtel's "OS 06 Control Strip Modules" (docs for
writing Control Strip modules, revised and corrected), and...

  Errata for Inside Macintosh:Networking

Yeah. That's right.  Rich Kubota and Scott Kuechle put together an
actual list of known errors in Inside Macintosh:Networking.  We have more
errata sheets under review, too.  When they get reviewed, we'll put them
up there as well.

For some help on getting started programming the Mac (and a desperate
plea for some feedback on said help), look at

 http://www.info.apple.com/dev/default.html

If you find this stuff useful, please let us know.  Thanks to Michelle
Wyner, ex-intern, and Mark Cookson for doing all the real work.

--Brian Bechtel     [e-mail]     "My opinion, not Apple's"

If you don't know all these buzzwords, go read a different newsgroup
until you do.  Don't ask me; hell, I made up half of them myself.

---------------------------

End of C.S.M.P. Digest
**********************


---------------------------------------------------------------------

NOTE:  The following Macintosh file(s) are enclosed with this
message, in BinHex format.  If your mail system does not convert
BinHex files automatically, you will need to transfer the message to
a Mac and run the BinHex application to decode it.

Filename: mylib.s.o    Size:  1688 bytes

---------------------------------------------------------------------

(This file must be converted with BinHex 4.0)